The present invention relates to a method for trapping HTTP logout events and for calling an application specific logout handle.
The identity market is growing rapidly as more and more users are falling victims to identity theft. Though there are many different identity products in the market, most of them are designed to protect applications and resources running on application servers or web servers. This is because most of the web sites visited either run on a web server or an application server. The existing products achieve the same end goals. They authenticate and authorize users to access various web-based resources. Once the user has been authenticated in web-based applications, there is a generic need to logout the user at some point of time (once the user is done with the application). Once the user triggers a logout event on a web application, it is required by identity products to trap such events and perform the necessary steps to trap logout events and perform certain housekeeping tasks (like destroying user sessions) specific to the application.
The following problems may be faced by a user may while trying to trap such a broad range of logout events.
There is no single standard for performing HTTP logouts on any application, whether it is a web application or any other HTTP browser-based application. Hence users are free to choose any mechanism through which they may prefer to logout. This makes the problem difficult for any vendor to come up with a generic solution that works for most cases.
Once the user triggers a logout by clicking a button or a URL (“Uniform Resource Locator”), the user may or may not be directed to a unique URI (Uniform Resource Identifier”) that can help the trapping mechanism to detect the logout event.
Some applications redirect the user to a specific URI, others (like portal applications) pass extra parameters in the query string to denote a logout event. Some applications embed specific information in the HTTP request such as headers or HTTP request parameters. Since the list of such mechanisms are endless due to the flexibility of the HTTP protocol, application developers are free to use any of the above-mentioned events to notify a logout. However, the innumerable ways through which the application can logout results in a non-trivial problem for any framework or vendor to trap such a huge range of logout events.
It is believed that none of the present vendors in the market has the ability to trap logout events based on a set of configurable criterions. Most of them use one or more of the above-mentioned techniques to trap a logout event.
Hence a single solution used by one vendor will not suffice for any generic J2EE web-based application.
What is needed, therefore, is a mechanism to trap logout events that is generic and extensible so that it can be configured depending upon the functionality of the end application.
Finally, even if some of the vendors have products that can trap a logout event and invalidate an HTTP session, it is believed that they do not have a mechanism to synchronize the HTTP session of the application as well as the HTTP session of an application/web/portal server. In other words, it is believed that the existing vendors do not have a mechanism to plug in a generic extensible logout handler that can be configured to perform the necessary steps for logout.
Even if a specific vendor provides such a solution for a specific logout event associated with a particular application running on a specific container, the chances that the same mechanism will work in a different environment or J2EE/web container is remote.
In sum, it is believed that no existing vendor has so far been able to provide a robust an extensible mechanism to trap logout events. Most of the existing solutions are too specific to the application server/web server used, or are application specific. Hence a particular existing solution in the market to trap a HTTP logout will not work in a different scenario.
What is desired, therefore, is a generic yet very flexible mechanism that can be used by a wide set of products, including identity products, to trap HTTP logout events and allow the user to perform any number of steps afterwards through a configurable logout handler.